The Atari Compendium/The Atari Compendium (Toad Computers) (1994).iso/files/umich/telecomm/fnordadl/fn132src.zoo/ref-man/theory.tex

Text File | 1991-09-02 | 27KB | 669 lines

@comment Tell Emacs to use -*-texinfo-*- mode
@comment $Id: theory.tex,v 2.4 91/09/01 23:04:49 royce Exp $

@node Sysop Theory, User Command Reference, Fifteen Minute Guide, Top
@chapter Sysop Theory
@cindex Theory
@cindex Sysop theory

Before getting into the nitty-gritty details of what buttons to push
to get which results, let us first force down your throat some theory about
what you're going to be dealing with.  You can forget about it after the
final exam, if you wish.

@node Your Callers, Rooms, Sysop Theory, Sysop Theory
@section Your Callers
@cindex Callers
@cindex Users, types of

You are presumably going through all of this because you
wish to have people of some type call your system and do something
with it.  These callers are your reason for running a @sc{bbs}.  While
other systems offer a vast array of access and status levels,
the general Citadel philosophy of simplicity holds here, meaning
that there are no real preferential user access levels.

Despite that fact, there do need to be some ways to handle
special cases.  @xref{User Status Commands}, for the commands to assign the
various user attributes.  As of this writing, the attributes are:

@itemize @bullet
@item
@cindex Sysop
@dfn{The Sysop}.  That's you, the System Operator, and there's only one of you
unless you share the duties with other people, or
somebody else has access to your computer while it's
running Fnordadel.  You can do anything within reason,
and a few things beyond reason.  Fnordadel allows you to define
the name used by the Sysop in @file{ctdlcnfg.sys}, using the parameter
@vindex sysop
@code{#sysop}.  You should set this up correctly.  (If your system really
has more than one Sysop, set the
@vindex sysop
@code{#sysop} parameter to whichever one
has direct access to the system or uses the system most, or just pick a name
from a hat.  Alternatively, leave
@vindex sysop
@code{#sysop} undefined.
@xref{The Sysop Command Reference}, for more discussion on Sysop matters.)

@item
@cindex Co-Sysop
@dfn{Co-Sysops}.  You may additionally designate any number of other
users on your system as ``Co-Sysops'', by assigning them Sysop privileges.
This means that they have virtually
unlimited ability to use any command, @emph{except} those in the
Sysop menu (accessed by @samp{^L} at the main room prompt).
To let such people have access to the Sysop menu as well, you need
to give them the system password.  Note that anyone who has
been given Sysop privs is also automatically given Aide privs.

@item
@cindex Aide
@dfn{Aides}.  These are people that you wish to have help you
operate, maintain and control your system.  They can do things
like delete, copy or move messages, and they may do a certain
amount of room editing, floor maintenance and other things.  In
general, however, they can't do much to change the basic nature
of things (e.g. alter networking parameters, do things involving
access to your storage devices, etc.).

@item
@cindex Twit
@dfn{Twits}.  These are users that you have decided are too
detrimental to have continued access to your system, but
whose user accounts you don't simply wish to kill, lest
they immediately sign back on again and continue where
they left off.  Twits have most commands disabled; this
includes the ability to post messages!

@item
Everybody else.  This is the group of people who are
not the Sysop, Co-Sysops, Aides, or Twits.  They comprise the bulk of
your user population, most likely.
@end itemize

Additionally, the Sysop has control over users' ability to do certain things like
send private mail, create new discussion rooms, and post in
networked rooms.  (Such rooms may well be connected to long-distance
systems, and we don't want irresponsible or evil
users causing big phone bills!)

When you first start your system, it is unlikely that you will
wish to grant Aide or Co-Sysop status to many of your users, since you probably
won't know many of them at all well.  Our advice is to take your time, and
pick out some people who will handle the positions responsibly.  If chosen
wisely, they will be an asset in controlling your system, and in making
creative contributions which prevent stagnation.

@node Rooms, Floors, Your Callers, Sysop Theory
@section Rooms
@cindex Rooms

Right from the start, Citadel made use of something called a
@cindex Room
@dfn{room} to contain messages on a related topic.  Fnordadel does
the same.  A room has a name up to 19 characters in length, which
presumably captures the gist of a topic to be discussed by the
messages in that room.  Some systems you may be familiar with make
use of ``message areas'', ``message bases'', ``SIGs'' (Special Interest
Groups), etc.  They are all basically analogous to rooms, but will
typically be few in number and cover broad, static topics.

Other systems make use of ``threads'', in which messages are
related to each other by a common subject field (for example) rather
than physical location.  Callers travel up and down the threads one
message at a time, and now and then jump to a new thread.  Still
other systems have no way to organise messages; they are all stored
in one giant mass that is hard to wade through as a user, and still
preserve one's sanity.

We feel that Citadel's room metaphor is much easier to use
than a threading scheme, offers better organization than one massive
message area, and permits better dynamic flow of discussion than
bulky SIGs or message bases.

As callers use your system, they will move from room to room
reading new messages, and posting replies as they see fit.  If the
topic of a room drifts off on a tangent (as is common), you as
Sysop may exercise control to bring it back on track, change its
name to suit the new trend of discussion, move the off-topic messages
into a newly-created room, or kill the room entirely if none of the
above options are worth the effort.

The basic room can be specialised in a number of ways to
meet various needs.  Some of the attributes are:

@itemize @bullet
@item
@cindex Permanent (room type)
@dfn{Permanent}.  Normally, empty rooms will be purged by the
system from time to time.  There is also a command for
doing this explicitly (see @code{.A(ide) D(elete-empty-rooms)} in
@ref{The .A(ide) command}).  You may
not always wish rooms to disappear if they go empty, so
you may designate them permanent, and they will stick
around.

@item
@cindex Anonymous (room type)
@dfn{Anonymous}.  Rooms of this type are used for discussions
where callers may wish to remain totally unidentified.
None of the usual message header information is stored or
shown by the system, just a message number.

@item
@cindex Private (room type)
@dfn{Private}.  These rooms are for carrying out activities
that are not to be viewed by all callers to the system.
Only users who are told of the complete room name are
able to get into it.  And once a user knows the room's
name, he can't be barred from it short of altering the
name and reinviting all the other users.

@item
@cindex Invitation-only (room type)
@dfn{Invitation-only}.  These rooms are just like the above
type, with one difference.  Users must be invited into
them with a system command; knowing the full name is not
sufficient to gain access.  If a caller's presence is no
longer desired, eviction from the room is also easily
possible, without choosing a new room name.

@item
@cindex Read-only (room type)
@dfn{Read-only}.  Rooms of this type can only have messages
entered in them by the Sysop, Co-Sysops or Aides.  A typical use for
such a room is for announcements that you wish people to
have access to, uncluttered by comments from other callers.

@item
@cindex Directory (room type)
@dfn{Directory}.  Rooms of this type are used to give callers
access to your storage device(s) (@sc{ram}, disk or hard drives),
for the purposes of file uploading and/or downloading.
Each directory room is tied to a specific disk directory
somewhere, so you can give different people access to
different collections of files.  Normal discussion
activities are permissable in directory rooms.

@item
@cindex Network (room type)
@cindex Shared (room type)
@dfn{Network} or @dfn{Shared}.  Rooms of this type are linked via the